Skip to content

Constify remaining traits/impls for const_ops #143949

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 3 commits into
base: master
Choose a base branch
from

Conversation

clarfonthey
Copy link
Contributor

@clarfonthey clarfonthey commented Jul 15, 2025

Tracking issue: #143802

This is split into three commits for ease of reviewability:

  1. Updates the forward_ref_* macros to accept multiple attributes (in anticipation of needing rust_const_unstable attributes) and also require attributes in these macros. Since the default attribute only helps for the initial implementations, it means it's easy to get wrong for future implementations, as shown for the saturating implementations which were incorrect before.
  2. Adds constness and trivial implementations to the remaining traits in core::ops::{arith,bits}.
  3. Constifies the rest of the reasonable implementations.

A few random other notes on the implementation specifically:

  • Unfortunately, without Tracking Issue for macro_named_capture_groups #142999 implemented, we can't make the constness in the forward_ref_* macros work nicely without copy-pasting the macro body. Instead of doing that, I decided to go for a cursed extra const argument, which is then used for the actual const keyword. I explicitly mention named macro capture groups as a way of doing this better in the comments.
  • I unindented the attributes that were passed to the forward_ref_* macro calls because in some places rustfmt wanted them to be unindented, and in others it was allowed because they were themselves inside of macro bodies. I chose the consistent indenting even though I (personally) think it looks worse.

As far as the actual changes go, this constifies the following additional traits:

  • Neg
  • Not
  • BitAnd
  • BitOr
  • BitXor
  • Shl
  • Shr
  • AddAssign
  • SubAssign
  • MulAssign
  • DivAssign
  • RemAssign
  • BitAndAssign
  • BitOrAssign
  • BitXorAssign
  • ShlAssign
  • ShrAssign

In terms of constified implementations of these traits, it adds the reference-forwarded versions of all the arithmetic operators, which are defined by the macros in library/core/src/internal_macros.rs. I'm not going to fully enumerate these because we'd be here all day, but sufficed to say, it effectively allows adding an & to one or both sides of an operator for primitives.

Additionally, I constified the implementations for Wrapping and Saturating as well, since all of them forward to already-const-stable methods.

There are three "non-primitive" types which implement these traits, listed below. Note that I put "non-primitive" in quotes since I'm including Wrapping and Saturating, which are just wrappers over primitives.

  • Duration (arithmetic operations)
  • Ipv4Addr (bit operations)
  • Ipv6Addr (bit operations)

Note

Concerns (0 active)

Managed by @rustbot—see help for details.

@rustbot
Copy link
Collaborator

rustbot commented Jul 15, 2025

r? @ibraheemdev

rustbot has assigned @ibraheemdev.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

@rustbot rustbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-clippy Relevant to the Clippy team. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. T-libs Relevant to the library team, which will review and decide on the PR/issue. labels Jul 15, 2025
@rustbot
Copy link
Collaborator

rustbot commented Jul 15, 2025

Some changes occurred in src/tools/clippy

cc @rust-lang/clippy

@rust-log-analyzer

This comment has been minimized.

@rust-log-analyzer

This comment has been minimized.

@@ -75,6 +76,7 @@ impl MulAssign<i64> for Wrap {
}
}

#[clippy::msrv = "1.88.0"]
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What is this for?

Copy link
Member

@samueltardieu samueltardieu Jul 15, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This hides a real issue: to know whether it can replace "a = a OP b" by "a OP= b" (where OP is, for example, "+"), Clippy looks for the const-stability of the sole associated item of the trait corresponding to "OP=". Here, AddAssign is now identified as const-stable, and Clippy attempts to replace a = a + b; by a += b; in a const context, when a is of a generic type implementing AddAssign.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes: I'm not quite sure whether this code should even remain on Clippy's side after this PR, since I'm pretty sure that "MSRV" doesn't account for nightly compilers, and we definitely won't want to ever stabilise an operator without its corresponding assign version. I chose the easiest approach to get it to pass without making too much of a modification, since it makes more sense to edit this in the clippy repo directly instead of via the subtree.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Filed rust-lang/rust-clippy#15285 to keep track of this.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In the meantime, you could go with https://rfc1149.pastes.sh/patch-assign-op-pattern.diff and remove the msrv attribute, and we'll take care of reintroducing the proper code in Clippy.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In the test, res = res + Self::ONE; cannot be replaced by res += Self::ONE in a const context because T (the type of res and Self::ONE) implements AddAssign, not [const] AddAssign (and it implements [const] Add, hence the valid + operation in the const context). But Clippy, if it stays unpatched, will suggest it because it only checks the constness of the AddAssign trait declaration, not its implementation.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If I am mistaken and this suggestion is valid, then instead of commenting the test, just add a //~^ assign_op_pattern below the res = res + Self::ONE; line and bless the results, but I think you'll get an invalid .fixed file.

Copy link
Contributor Author

@clarfonthey clarfonthey Jul 17, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Oh, you're totally correct here; I was mistaken. So, this is a genuine bug, but it's unrelated to the actual issue at hand, IMHO: it should also suggest to replace [const] Add with [const] AddAssign, or add it. Or at least make it not an automatically applicable thing. It has nothing to do with the const stability of the trait, but the const bound on the trait.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Indeed, this is a genuine bug in Clippy, but it activates only when your PR goes in, unless you apply something similar to the patch at https://rfc1149.pastes.sh/patch-assign-op-pattern.diff which neutralizes the bug.

If you prefer, I can submit this patch as a PR to the current repository to neutralize the bug before the current PR gets merged, but this will be no better than integrating it as part of this PR. I don't suggest to submit it to the Clippy repo, as it won't get merged into the compiler repo before the next sync on July 24.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That's fair, and now that I understand, I'll go with your patch instead.

@rustbot
Copy link
Collaborator

rustbot commented Jul 16, 2025

Only organization members can add or resolve concerns.

@rust-log-analyzer

This comment has been minimized.

@samueltardieu
Copy link
Member

@rustbot concern May break Clippy

(checking if concerns work as top-level comments only, real concern was written here, and discussion about the error message is on Zulip)

@rustbot rustbot added the S-waiting-on-concerns Status: Awaiting concerns to be addressed by the author label Jul 16, 2025
@samueltardieu
Copy link
Member

@rustbot resolve May break Clippy

We cleared up the misunderstanding of what the problem was.

@rustbot rustbot removed the S-waiting-on-concerns Status: Awaiting concerns to be addressed by the author label Jul 17, 2025
@rust-log-analyzer

This comment has been minimized.

@clarfonthey
Copy link
Contributor Author

Yeah, I'll be honest, I have genuinely no idea what those tests are doing. I could just add the feature flag, but it wasn't necessary before, and I don't know why.

@samueltardieu
Copy link
Member

Yeah, I'll be honest, I have genuinely no idea what those tests are doing. I could just add the feature flag, but it wasn't necessary before, and I don't know why.

Didn't you just forget to replace #![feature(const_ops)] in library/coretests/tests/lib.rs?

Comment on lines 3 to 4
#![feature(const_arith_ops)]
#![feature(const_trait_impl)]
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If you keep both into a single #![feature] inner attribute, then it won't make a difference in line numbers in the stderr files (after you're reblessed the tests).

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I know, but I don't like compromising formatting just because of the line number changes.

@clarfonthey
Copy link
Contributor Author

clarfonthey commented Jul 18, 2025

Didn't you just forget to replace #![feature(const_ops)] in library/coretests/tests/lib.rs?

Last time I checked this file, it didn't have it, but now it does. 🤷🏻

Literally tried rg const_ops in the library folder and got nothing last time, now it worked, so, issue fixed I guess.

@RalfJung
Copy link
Member

TBH I think it'd be fine to have arith and bit ops in the same feature gate. We don't need a dozen of them, and it seems likely we'd stabilize these together.

@clarfonthey
Copy link
Contributor Author

clarfonthey commented Jul 18, 2025

That's fair. I could combine the bit ops I've already gotten working into this PR, I just figured that it made more sense to separate them.

Part of my reason was to just simplify the review, but I guess that the compiler is used to 100-file changes, so… 🤷🏻

I also thought there would be more implementations to constify but for the arithmetic side it's just Duration as the odd one out, and for bit operations it's Ipv[46]Addr. So, not groundbreaking.

@clarfonthey clarfonthey changed the title Tidy up const_ops, rename to const_arith_ops Constify remaining traits/impls for const_ops Jul 18, 2025
@clarfonthey
Copy link
Contributor Author

Okay, I went for it and just incorporated the bit operations in this PR and undid the rename. After this, "all" of the operators are constified.

I say "all" because I'm excluding the Index and Deref operators, which deserve separate handling.

&& !is_stable_const_fn(cx, *binop_id, msrv)
{
// FIXME: reintroduce a better check after this is merged back into Clippy
if is_in_const_context(cx) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Wouldn't we want to check for tcx.features().const_ops()? (I'm not being able to find const_ops on Features)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-clippy Relevant to the Clippy team. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. T-libs Relevant to the library team, which will review and decide on the PR/issue.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

8 participants